ADA Programming Guide/ADA Programming Guide.iso/ada_lrm/chap11.doc

Text File | 1996-01-30 | 35KB | 816 lines

                              11. Exceptions


This  chapter  defines  the  facilities  for  dealing  with errors or other
exceptional  situations  that  arise  during  program  execution.   Such  a
situation  is  called  an  exception.   To raise an exception is to abandon
normal program execution so as to draw  attention  to  the  fact  that  the
corresponding situation has arisen.  Executing some actions, in response to
the arising of an exception, is called handling the exception.


An  exception  declaration  declares a name for an exception.  An exception
can be raised by a  raise  statement,  or  it  can  be  raised  by  another
statement  or  operation  that propagates the exception.  When an exception
arises, control can be transferred to a user-provided exception handler  at
the  end  of  a  block statement or at the end of the body of a subprogram,
package, or task unit.


References:  block statement 5.6, error situation  1.6,  exception  handler
11.2,  name  4.1,  package  body  7.1,  propagation  of an exception 11.4.1
11.4.2, raise statement 11.3, subprogram body 6.3, task body 9.1

11.1  Exception Declarations


An exception declaration declares a name for an exception.  The name of  an
exception  can  only  be  used in raise statements, exception handlers, and
renaming declarations.


    exception_declaration ::= identifier_list : exception;


An exception declaration  with  several  identifiers  is  equivalent  to  a
sequence  of  single  exception  declarations, as explained in section 3.2.
Each  single  exception  declaration  declares  a  name  for  a   different
exception.   In  particular,  if  a  generic  unit  includes  an  exception
declaration, the exception declarations implicitly generated  by  different
instantiations  of  the  generic unit refer to distinct exceptions (but all
have  the  same  identifier).   The  particular  exception  denoted  by  an
exception name is determined at compilation time and is the same regardless
of  how  many  times the exception declaration is elaborated.  Hence, if an
exception declaration occurs in a recursive subprogram, the exception  name
denotes the same exception for all invocations of the recursive subprogram.


The  following  exceptions are predefined in the language;  they are raised
when the situations described are detected.


CONSTRAINT_ERROR  This  exception  is  raised  in  any  of  the   following
                  situations:    upon   an   attempt  to  violate  a  range
                  constraint,  an  index  constraint,  or  a   discriminant
                  constraint;   upon  an  attempt to use a record component
                  that does not exist for the current discriminant  values;
                  and  upon  an  attempt  to  use  a selected component, an
                  indexed component, a slice, or an attribute, of an object
                  designated by an access value, if  the  object  does  not
                  exist because the access value is null.


   NUMERIC_ERROR  This exception is raised by the execution of a predefined
                  numeric  operation  that  cannot deliver a correct result
                  (within the declared  accuracy  for  real  types);   this
                  includes   the   case  where  an  implementation  uses  a
                  predefined   numeric   operation   for   the   execution,
                  evaluation,  or elaboration of some construct.  The rules
                  given in section 4.5.7  define  the  cases  in  which  an
                  implementation  is  not  required to raise this exception
                  when such an error situation arises;   see  also  section
                  11.6.


   PROGRAM_ERROR  This exception is  raised  upon  an  attempt  to  call  a
                  subprogram, to activate a task, or to elaborate a generic
                  instantiation,  if the body of the corresponding unit has
                  not yet been elaborated.  This exception is  also  raised
                  if the end of a function is reached (see 6.5);  or during
                  the  execution of a selective wait that has no else part,
                  if this execution determines that  all  alternatives  are
                  closed   (see   9.7.1).    Finally,   depending   on  the
                  implementation, this exception  may  be  raised  upon  an
                  attempt  to  execute an action that is erroneous, and for
                  incorrect order dependences (see 1.6).


   STORAGE_ERROR  This  exception  is  raised  in  any  of  the   following
                  situations:  when the dynamic storage allocated to a task
                  is  exceeded;   during the evaluation of an allocator, if
                  the space  available  for  the  collection  of  allocated
                  objects  is  exhausted;   or  during the elaboration of a
                  declarative item, or during the execution of a subprogram
                  call, if storage is not sufficient.


   TASKING_ERROR  This exception is raised  when  exceptions  arise  during
                  intertask communication (see 9 and 11.5).

Note:


The  situations described above can arise without raising the corresponding
exceptions, if the pragma SUPPRESS has been used to give permission to omit
the corresponding checks (see 11.7).


Examples of user-defined exception declarations:

    SINGULAR : exception;
    ERROR    : exception;
    OVERFLOW, UNDERFLOW : exception;


References:  access value 3.8, collection 3.8, declaration  3.1,  exception
11,  exception handler 11.2, generic body 12.2, generic instantiation 12.3,
generic unit 12, identifier 2.3, implicit declaration  12.3,  instantiation
12.3,  name  4.1, object 3.2, raise statement 11.3, real type 3.5.6, record
component 3.7, return statement 5.8, subprogram  6,  subprogram  body  6.3,
task 9, task body 9.1


Constraint_error exception contexts:  aggregate 4.3.1 4.3.2, allocator 4.8,
assignment  statement  5.2 5.2.1, constraint 3.3.2, discrete type attribute
3.5.5, discriminant constraint  3.7.2,  elaboration  of  a  generic  formal
parameter  12.3.1  12.3.2  12.3.4  12.3.5,  entry index 9.5, exponentiating
operator 4.5.6, index constraint 3.6.1, indexed  component  4.1.1,  logical
operator  4.5.1, null access value 3.8, object declaration 3.2.1, parameter
association 6.4.1, qualified expression 4.7, range constraint 3.5, selected
component 4.1.3, slice 4.1.2, subtype indication 3.3.2, type conversion 4.6


Numeric_error exception contexts:  discrete type attribute 3.5.5,  implicit
conversion  3.5.4 3.5.6 4.6, numeric operation 3.5.5 3.5.8 3.5.10, operator
of a numeric type 4.5 4.5.7


Program_error  exception  contexts:   collection  3.8,   elaboration   3.9,
elaboration  check  3.9  7.3  9.3  12.2,  erroneous  1.6,  incorrect  order
dependence 1.6, leaving a function 6.5, selective wait 9.7.1


Storage_error exception contexts:  allocator 4.8


Tasking error exception contexts:  abort statement  9.10,  entry  call  9.5
9.7.2 9.7.3, exceptions during task communication 11.5, task activation 9.3

11.2  Exception Handlers


The  response  to  one  or  more  exceptions  is  specified by an exception
handler.


    exception_handler ::=
       when exception_choice {| exception_choice} =>
          sequence_of_statements

    exception_choice ::= exception_name | others


An exception handler occurs in a construct that is either a block statement
or the body of a subprogram, package, task unit, or generic unit.   Such  a
construct  will be called a frame in this chapter.  In each case the syntax
of a frame that has exception handlers includes the following part:


    begin
        sequence_of_statements
    exception
        exception_handler
       {exception_handler}
    end


The exceptions denoted by the exception names given as exception choices of
a frame must all be distinct.  The exception choice others is only  allowed
for the last exception handler of a frame and as its only exception choice;
it  stands for all exceptions not listed in previous handlers of the frame,
including exceptions whose names are  not  visible  at  the  place  of  the
exception handler.


The  exception handlers of a frame handle exceptions that are raised by the
execution of the sequence of  statements  of  the  frame.   The  exceptions
handled  by  a given exception handler are those named by the corresponding
exception choices.


Example:

    begin
       --  sequence of statements
    exception
       when SINGULAR | NUMERIC_ERROR =>
          PUT(" MATRIX IS SINGULAR ");
       when others =>
          PUT(" FATAL ERROR ");
          raise ERROR;
    end;

Note:


The same kinds of statement are allowed in the sequence  of  statements  of
each  exception handler as are allowed in the sequence of statements of the
frame.   For example, a return statement is allowed in a handler  within  a
function body.


References:   block  statement  5.6,  declarative  part  3.9, exception 11,
exception handling 11.4, function body 6.3, generic body 12.2, generic unit
12.1, name 4.1, package body 7.1, raise statement  11.3,  return  statement
5.8,  sequence  of  statements  5.1, statement 5, subprogram body 6.3, task
body 9.1, task unit 9 9.1, visibility 8.3

11.3  Raise Statements


A raise statement raises an exception.


    raise_statement ::= raise [exception_name];


For the execution of a raise statement with an exception  name,  the  named
exception  is  raised.  A raise statement without an exception name is only
allowed within an  exception  handler  (but  not  within  the  sequence  of
statements  of  a subprogram, package, task unit, or generic unit, enclosed
by the handler);  it raises again the exception that caused transfer to the
innermost enclosing handler.


Examples:

    raise SINGULAR;
    raise NUMERIC_ERROR;  --  explicitly raising a predefined exception

    raise;                --  only within an exception handler


References:  exception 11, generic unit 12, name 4.1, package  7,  sequence
of statements 5.1, subprogram 6, task unit 9

11.4  Exception Handling


When  an  exception  is  raised,  normal program execution is abandoned and
control is transferred to an exception  handler.   The  selection  of  this
handler  depends on whether the exception is raised during the execution of
statements or during the elaboration of declarations.


References:  declaration 3.1, elaboration 3.1 3.9, exception 11,  exception
handler 11.2, raising of exceptions 11.3, statement 5

11.4.1  Exceptions Raised During the Execution of Statements


The  handling  of  an  exception  raised  by the execution of a sequence of
statements depends on whether the innermost frame or accept statement  that
encloses the sequence of statements is a frame or an accept statement.  The
case  where  an accept statement is innermost is described in section 11.5.
The case where a frame is innermost is presented here.


Different actions take place, depending on whether or not this frame has  a
handler  for  the  exception, and on whether the exception is raised in the
sequence of statements of the frame or in that of an exception handler.


If an exception is raised in the sequence of statements of a frame that has
a handler for the exception, execution of the sequence of statements of the
frame is abandoned and control is transferred  to  the  exception  handler.
The  execution  of  the sequence of statements of the handler completes the
execution of the frame (or its elaboration if the frame is a package body).


If an exception is raised in the sequence of statements  of  a  frame  that
does  not  have  a handler for the exception, execution of this sequence of
statements is abandoned.  The next action depends  on  the  nature  of  the
frame:


(a)  For a subprogram body, the same exception is raised again at the point
     of  call  of the subprogram, unless the subprogram is the main program
     itself, in which case execution of the main program is abandoned.


(b)  For a block statement, the same exception is raised again  immediately
     after  the  block  statement  (that is, within the innermost enclosing
     frame or accept statement).


(c)  For a package body that is a declarative item, the same  exception  is
     raised  again  immediately  after  this  declarative  item (within the
     enclosing declarative part). If the package body is that of a subunit,
     the exception is raised again at the place of the  corresponding  body
     stub.  If the package is a library unit, execution of the main program
     is abandoned.


(d)  For a task body, the task becomes completed.


An exception that is raised again (as in the above cases (a), (b), and (c))
is  said  to  be propagated, either by the execution of the subprogram, the
execution of the block statement, or the elaboration of the  package  body.
No  propagation  takes place in the case of a task body.  If the frame is a
subprogram or a  block  statement  and  if  it  has  dependent  tasks,  the
propagation  of  an  exception  takes  place  only after termination of the
dependent tasks.


Finally, if an exception is raised in the  sequence  of  statements  of  an
exception  handler,  execution of this sequence of statements is abandoned.
Subsequent actions (including propagation, if any) are as in the cases  (a)
to (d) above, depending on the nature of the frame.


Example:

    function FACTORIAL (N : POSITIVE) return FLOAT is
    begin
       if N = 1 then
          return 1.0;
       else
          return FLOAT(N) * FACTORIAL(N-1);
       end if;
    exception
       when NUMERIC_ERROR => return FLOAT'SAFE_LARGE;
    end FACTORIAL;


If  the  multiplication  raises  NUMERIC_ERROR,  then  FLOAT'SAFE_LARGE  is
returned by the handler.   This  value  will  cause  further  NUMERIC_ERROR
exceptions  to be raised by the evaluation of the expression in each of the
remaining invocations of the function, so that for large values  of  N  the
function will ultimately return the value FLOAT'SAFE_LARGE.


Example:

    procedure P is
       ERROR : exception;
       procedure R;

       procedure Q is
       begin
          R;
          ...            --  error situation (2)
       exception
          ...
          when ERROR =>  --  handler E2
          ...
       end Q;

       procedure R is
       begin
          ...            --  error situation (3)
       end R;

    begin
       ...               --  error situation (1)
       Q;
       ...
    exception
       ...
       when ERROR =>     --  handler E1
       ...
    end P;


The following situations can arise:


(1)  If the exception ERROR is raised in the sequence of statements of  the
     outer  procedure  P,  the  handler  E1  provided  within  P is used to
     complete the execution of P.


(2)  If the exception ERROR is raised in the sequence of statements  of  Q,
     the  handler E2 provided within Q is used to complete the execution of
     Q.  Control will be returned to the point of call of Q upon completion
     of the handler.


(3)  If the exception ERROR is raised in the body of R, called  by  Q,  the
     execution  of  R  is abandoned and the same exception is raised in the
     body of Q.  The handler E2 is then used to complete the  execution  of
     Q, as in situation (2).


Note  that  in  the  third  situation, the exception raised in R results in
(indirectly) transferring control to a handler that is part of Q and  hence
not  enclosed by R.  Note also that if a handler were provided within R for
the exception choice others, situation (3) would cause  execution  of  this
handler, rather than direct termination of R.


Lastly,  if ERROR had been declared in R, rather than in P, the handlers E1
and E2  could  not  provide  an  explicit  handler  for  ERROR  since  this
identifier would not be visible within the bodies of P and Q.  In situation
(3), the exception could however be handled in Q by providing a handler for
the exception choice others.

Notes:


The  language  does  not define what happens when the execution of the main
program is abandoned after an unhandled exception.


The predefined exceptions are those that can be  propagated  by  the  basic
operations and the predefined operators.


The  case of a frame that is a generic unit is already covered by the rules
for subprogram and package bodies, since the sequence of statements of such
a frame is not executed but is the template for the corresponding sequences
of  statements  of  the  subprograms  or  packages  obtained   by   generic
instantiation.


References:   accept  statement 9.5, basic operation 3.3.3, block statement
5.6, body stub 10.2, completion 9.4, declarative item 3.9, declarative part
3.9, dependent task 9.4,  elaboration  3.1  3.9,  exception  11,  exception
handler  11.2,  frame  11.2,  generic  instantiation 12.3, generic unit 12,
library unit 10.1, main program 10.1, numeric_error exception 11.1, package
7, package body 7.1, predefined operator 4.5, procedure  6.1,  sequence  of
statements  5.1, statement 5, subprogram 6, subprogram body 6.3, subprogram
call 6.4, subunit 10.2, task 9, task body 9.1

11.4.2  Exceptions Raised During the Elaboration of Declarations


If an exception is raised during the elaboration of the declarative part of
a given frame, this elaboration is abandoned.  The next action  depends  on
the nature of the frame:


(a)  For a subprogram body, the same exception is raised again at the point
     of  call  of the subprogram, unless the subprogram is the main program
     itself, in which case execution of the main program is abandoned.


(b)  For a block statement, the same exception is raised again  immediately
     after the block statement.


(c)  For a package body that is a declarative item, the same  exception  is
     raised again immediately after this declarative item, in the enclosing
     declarative  part.   If  the  package  body  is that of a subunit, the
     exception is raised again at the place of the corresponding body stub.
     If the package is a library unit, execution of  the  main  program  is
     abandoned.


(d)  For a task  body,  the  task  becomes  completed,  and  the  exception
     TASKING_ERROR  is  raised  at  the point of activation of the task, as
     explained in section 9.3.


Similarly, if an exception is raised during the  elaboration  of  either  a
package  declaration  or a task declaration, this elaboration is abandoned;
the next action depends on the nature of the declaration.


(e)  For a package declaration or a task declaration, that is a declarative
     item, the exception is raised again immediately after the  declarative
     item  in the enclosing declarative part or package specification.  For
     the declaration of a  library  package,  the  execution  of  the  main
     program is abandoned.


An  exception that is raised again (as in the above cases (a), (b), (c) and
(e)) is said to be propagated, either by the execution of the subprogram or
block statement, or by the elaboration of  the  package  declaration,  task
declaration or package body.


Example  of an exception in the declarative part of a block statement (case
(b)):

    procedure P is
       ...
    begin
       declare
          N : INTEGER := F;  --  the function F may raise ERROR
       begin
          ...
       exception
          when ERROR =>      --  handler E1
       end;
       ...
    exception
       when ERROR =>         --  handler E2
    end P;

    --  if the exception ERROR is raised in the declaration of N, it is handled by E2


References:  activation 9.3, block statement 5.6, body stub 10.2, completed
task 9.4, declarative item 3.9, declarative part 3.9, elaboration 3.1  3.9,
exception  11,  frame  11.2,  library unit 10.1, main program 10.1, package
body 7.1, package declaration 7.1, package specification 7.1, subprogram 6,
subprogram body 6.3, subprogram call 6.4, subunit 10.2, task 9,  task  body
9.1, task declaration 9.1, tasking_error exception 11.1

11.5  Exceptions Raised During Task Communication


An  exception  can  be propagated to a task communicating, or attempting to
communicate, with another task.  An exception can also be propagated  to  a
calling task if the exception is raised during a rendezvous.


When  a task calls an entry of another task, the exception TASKING_ERROR is
raised in the calling task, at the place of the call, if the called task is
completed before accepting the entry call or is already  completed  at  the
time of the call.


A rendezvous can be completed abnormally in two cases:


(a)  When an exception is  raised  within  an  accept  statement,  but  not
     handled  within  an  inner  frame.  In this case, the execution of the
     accept statement is abandoned and the same exception is  raised  again
     immediately  after  the  accept  statement within the called task; the
     exception is also propagated to the calling task at the point  of  the
     entry call.


(b)  When the task containing the accept statement is completed  abnormally
     as  the  result  of  an  abort statement.  In this case, the exception
     TASKING_ERROR is raised in the calling task at the point of the  entry
     call.


On the other hand, if a task issuing an entry call becomes abnormal (as the
result  of  an  abort statement) no exception is raised in the called task.
If the rendezvous has not yet started, the entry call is cancelled.  If the
rendezvous is in progress, it completes normally, and the  called  task  is
unaffected.


References:   abnormal  task  9.10,  abort statement 9.10, accept statement
9.5, completed  task  9.4,  entry  call  9.5,  exception  11,  frame  11.2,
rendezvous  9.5, task 9, task termination 9.4, tasking_error exception 11.1

11.6  Exceptions and Optimization


The purpose of this section is to specify the  conditions  under  which  an
implementation  is  allowed  to  perform  certain actions either earlier or
later than specified by other rules of the language.


In general, when the language rules specify an order  for  certain  actions
(the  canonical order), an implementation may only use an alternative order
if it can guarantee that the effect of the program is not  changed  by  the
reordering.   In particular, no exception should arise for the execution of
the reordered program if none arises for the execution of  the  program  in
the canonical order.  When, on the other hand, the order of certain actions
is   not   defined   by  the  language,  any  order  can  be  used  by  the
implementation.  (For example, the arguments of a predefined  operator  can
be  evaluated  in  any   order  since the rules given in section 4.5 do not
require a specific order of evaluation.)


Additional freedom is left to  an  implementation  for  reordering  actions
involving  predefined  operations  that  are either predefined operators or
basic operations other than assignments.  This freedom is left, as  defined
below,  even in the case where the execution of these predefined operations
may propagate a (predefined) exception:


(a)  For the purpose of establishing whether the same effect is obtained by
     the  execution  of  certain  actions  in  the  canonical  and  in   an
     alternative  order,  it  can  be  assumed  that none of the predefined
     operations  invoked  by  these  actions  propagates   a   (predefined)
     exception, provided that the two following requirements are met by the
     alternative  order:   first,  an  operation must not be invoked in the
     alternative order if  it  is  not  invoked  in  the  canonical  order;
     second,  for  each  operation, the innermost enclosing frame or accept
     statement must be  the  same  in  the  alternative  order  as  in  the
     canonical order, and the same exception handlers must apply.


(b)  Within an expression, the association of operators  with  operands  is
     specified  by  the  syntax.   However,  for  a  sequence of predefined
     operators of  the  same  precedence  level  (and  in  the  absence  of
     parentheses  imposing  a  specific  association),  any  association of
     operators with operands is  allowed  if  it  satisfies  the  following
     requirement:   an  integer  result  must be equal to that given by the
     canonical left-to-right order;  a  real  result  must  belong  to  the
     result  model  interval  defined for the canonical left-to-right order
     (see 4.5.7).  Such a reordering is allowed even if it  may  remove  an
     exception, or introduce a further predefined exception.


Similarly,  additional  freedom  is  left  to  an  implementation  for  the
evaluation  of  numeric  simple  expressions.   For  the  evaluation  of  a
predefined  operation, an implementation is allowed to use the operation of
a type that has a range wider than that of the base type of  the  operands,
provided  that  this  delivers  the  exact  result  (or a result within the
declared accuracy, in the case of a real type), even if  some  intermediate
results   lie   outside   the  range  of  the  base  type.   The  exception
NUMERIC_ERROR need not be raised in such a case.   In  particular,  if  the
numeric  expression  is an operand of a predefined relational operator, the
exception NUMERIC_ERROR need  not  be  raised  by  the  evaluation  of  the
relation, provided that the correct BOOLEAN result is obtained.


A  predefined  operation  need  not be invoked at all, if its only possible
effect is to propagate a predefined  exception.   Similarly,  a  predefined
operation  need  not  be invoked if the removal of subsequent operations by
the above rule renders this invocation ineffective.

Notes:


Rule (b) applies to predefined  operators  but  not  to  the  short-circuit
control forms.


The  expression  SPEED  <  300_000.0  can  be replaced by TRUE if the value
300_000.0 lies outside the base type of SPEED,  even  though  the  implicit
conversion  of the numeric literal would raise the exception NUMERIC_ERROR.


Example:

    declare
       N : INTEGER;
    begin
       N := 0;               --  (1)
       for J in 1 .. 10 loop
          N := N + J**A(K);  --  A and K are global variables
       end loop;
       PUT(N);
    exception
       when others => PUT("Some error arose"); PUT(N);
    end;


The evaluation of A(K) may be  performed  before  the  loop,  and  possibly
immediately before the assignment statement (1) even if this evaluation can
raise  an exception.  Consequently, within the exception handler, the value
of N is either the undefined initial value or a value later  assigned.   On
the  other  hand, the evaluation of A(K) cannot be moved before begin since
an exception would then be  handled  by  a  different  handler.   For  this
reason, the initialization of N in the declaration itself would exclude the
possibility of having an undefined initial value of N in the handler.


References:   accept  statement  9.5,  accuracy  of  real operations 4.5.7,
assignment 5.2, base type 3.3, basic operation 3.3.3, conversion 4.6, error
situation  11,  exception  11,  exception   handler   11.2,   frame   11.2,
numeric_error   exception   11.1,   predefined   operator  4.5,  predefined
subprogram  8.6,  propagation  of  an  exception  11.4,  real  type  3.5.6,
undefined value 3.2.1

11.7  Suppressing Checks


The  presence of a SUPPRESS pragma gives permission to an implementation to
omit certain run-time checks.  The form of this pragma is as follows:

    pragma SUPPRESS(identifier [, [ON =>] name]);


The identifier is that of the check that can  be  omitted.   The  name  (if
present)  must  be  either  a  simple  name or an expanded name and it must
denote either an object, a type or subtype, a task unit, or a generic unit;
alternatively the name can be a subprogram name, in which case it can stand
for several visible overloaded subprograms.


A pragma SUPPRESS is only allowed immediately within a declarative part  or
immediately  within  a package specification.  In the latter case, the only
allowed form is with a name that denotes an entity (or  several  overloaded
subprograms)  declared  immediately  within the package specification.  The
permission to omit the given check extends from the place of the pragma  to
the  end  of the declarative region associated with the innermost enclosing
block statement  or  program  unit.   For  a  pragma  given  in  a  package
specification,  the permission extends to the end of the scope of the named
entity.


If the pragma includes a name, the permission to omit the  given  check  is
further restricted:  it is given only for operations on the named object or
on all objects of the base type of a named type or subtype;  for calls of a
named subprogram;  for activations of tasks of the named task type;  or for
instantiations of the given generic unit.


The  following  checks  correspond  to  situations  in  which the exception
CONSTRAINT_ERROR may be raised; for these checks,  the  name  (if  present)
must denote either an object or a type.


ACCESS_CHECK          When  accessing  a  selected  component,  an  indexed
                      component,  a  slice,  or  an attribute, of an object
                      designated by an access value, check that the  access
                      value is not null.


DISCRIMINANT_CHECK    Check that a discriminant of a  composite  value  has
                      the  value  imposed  by  a  discriminant  constraint.
                      Also, when accessing a record component,  check  that
                      it exists for the current discriminant values.


INDEX_CHECK           Check that the bounds of an array value are equal  to
                      the  corresponding  bounds  of  an  index constraint.
                      Also, when accessing a component of an array  object,
                      check  for  each dimension that the given index value
                      belongs to the range defined by  the  bounds  of  the
                      array  object.   Also,  when  accessing a slice of an
                      array object, check that the given discrete range  is
                      compatible  with  the  range defined by the bounds of
                      the array object.


LENGTH_CHECK          Check that there is a  matching  component  for  each
                      component   of   an  array,  in  the  case  of  array
                      assignments, type conversions, and logical  operators
                      for arrays of boolean components.


RANGE_CHECK           Check that a  value  satisfies  a  range  constraint.
                      Also,  for  the  elaboration of a subtype indication,
                      check that the constraint (if present) is  compatible
                      with  the  type  mark.  Also, for an aggregate, check
                      that an index or discriminant value  belongs  to  the
                      corresponding   subtype.    Finally,  check  for  any
                      constraint   checks   performed    by    a    generic
                      instantiation.


The  following  checks  correspond  to  situations  in  which the exception
NUMERIC_ERROR is raised.  The  only  allowed  names  in  the  corresponding
pragmas are names of numeric types.


DIVISION_CHECK        Check that the second operand is  not  zero  for  the
                      operations /, rem and mod.


OVERFLOW_CHECK        Check that the result of a numeric operation does not
                      overflow.


The  following  check  corresponds  to  situations  in  which the exception
PROGRAM_ERROR is raised.  The  only  allowed  names  in  the  corresponding
pragmas are names denoting task units, generic units, or subprograms.


ELABORATION_CHECK     When either a subprogram is called, a task activation
                      is   accomplished,  or  a  generic  instantiation  is
                      elaborated, check that the body of the  corresponding
                      unit has already been elaborated.


The  following  check  corresponds  to  situations  in  which the exception
STORAGE_ERROR is raised.  The  only  allowed  names  in  the  corresponding
pragmas are names denoting access types, task units, or subprograms.


STORAGE_CHECK         Check that execution of an allocator does not require
                      more space than is available for a collection.  Check
                      that the space available for a task or subprogram has
                      not been exceeded.


If  an  error situation arises in the absence of the corresponding run-time
checks, the execution of the program is  erroneous  (the  results  are  not
defined by the language).


Examples:

    pragma SUPPRESS(RANGE_CHECK);
    pragma SUPPRESS(INDEX_CHECK, ON => TABLE);

Notes:


For certain implementations, it may be impossible or too costly to suppress
certain  checks.  The corresponding SUPPRESS pragma can be ignored.  Hence,
the occurrence of such a pragma within a given unit does not guarantee that
the corresponding exception will not arise;  the  exceptions  may  also  be
propagated by called units.


References:
access type 3.8, access value 3.8, activation 9.3, aggregate 4.3, allocator
4.8,  array  3.6,  attribute  4.1.4,  block  statement 5.6, collection 3.8,
compatible 3.3.2, component of an array 3.6, component  of  a  record  3.7,
composite  type  3.3,  constraint  3.3,  constraint_error  exception  11.1,
declarative part 3.9, designate 3.8, dimension  3.6,  discrete  range  3.6,
discriminant  3.7.1,  discriminant  constraint  3.7.2, elaboration 3.1 3.9,
erroneous 1.6, error situation 11, expanded name 4.1.3, generic body  11.1,
generic  instantiation  12.3,  generic  unit 12, identifier 2.3, index 3.6,
index constraint 3.6.1, indexed component 4.1.1,  null  access  value  3.8,
numeric  operation  3.5.5  3.5.8  3.5.10,  numeric  type 3.5, numeric_error
exception 11.1, object 3.2, operation  3.3.3,  package  body  7.1,  package
specification  7.1,  pragma 2.8, program_error exception 11.1, program unit
6, propagation of an exception 11.4, range constraint 3.5, record type 3.7,
simple name 4.1, slice 4.1.2, subprogram 6, subprogram body 6.3, subprogram
call 6.4, subtype 3.3, subunit 10.2, task 9, task body 9.1, task type  9.1,
task unit 9, type 3.3, type mark 3.3.2